Bug: double signal resolution with deploy-generated workers.

The deploy-generated worker entry (deploy.ts line ~502) calls handler.fetch(request, env, ctx) — which is this file. Since the deploy worker passes env (which has ASSETS), this block resolves the signal and returns a fully-formed asset response. Then back in the deploy worker, resolveStaticAssetSignal is called again on that response.

The second call is a no-op (header is stripped), but it still:

• Scans headers looking for x-vinext-static-file
• Allocates an unnecessary function call + buildHeaderRecord

More importantly, it's confusing — two layers both claim responsibility for the same signal.

Consider gating this on a condition that indicates no outer wrapper will handle it, or remove the signal handling from one of the two layers. The simplest fix: since app-router-entry.ts is the shared entry used by both direct wrangler usage and deploy-generated workers, and the deploy worker always wraps it, maybe this block should only run when there's no outer resolveStaticAssetSignal caller. One approach: only resolve here if there is no image optimization handler wrapping this (i.e., the user is using app-router-entry directly in wrangler.jsonc without a custom worker).

Alternatively, just remove the signal resolution from deploy.ts since app-router-entry.ts already handles it.

The intent of this condition could use a comment. When assetResponse.ok is false (e.g., 404 from the asset layer), the middleware status is dropped and the asset's error status is returned directly. When the asset is found but middleware set a non-200 status (e.g., 403 via rewrite), the middleware status overrides.

This seems correct (don't override a real 404 with a middleware 403), but it's non-obvious. A one-liner would help:

This basePath 404 guard is a meaningful behavioral change beyond "serve public files." Previously, requests without the basePath prefix could fall through to catch-all routes or middleware; now they get a hard 404.

This matches Next.js behavior and is probably correct, but it should be called out in the PR description since it changes observable behavior for any app with basePath configured. The /__vinext/ exception is good — internal endpoints need to bypass.

Worth noting: this also blocks middleware from seeing non-basePath requests. In Next.js, middleware's matcher config controls this, but here the 404 fires before middleware runs. This is consistent with how Next.js handles it (basePath rejection is early), but should be verified.

Nit: the .rsc suffix check prevents RSC data fetches from being intercepted, which is correct. But there's no guard against POST requests to public file paths that happen to match (e.g., a form submission to /logo/logo.svg). The GET || HEAD check handles this — just confirming that's intentional and sufficient.

Also, cleanPathname here is post-middleware-rewrite, which means middleware can rewrite any path to serve a public file. This matches Next.js semantics (middleware rewrites are applied before filesystem route matching).

Good: cancelResponseBody is called after tryServeStatic regardless of success. This correctly cleans up the signal response's body (which is null anyway, but defensive).

One edge case: if tryServeStatic throws (e.g., filesystem error mid-stream after headers are sent), the response body of the signal is still cancelled, but res may be in an inconsistent state. The outer try/catch at line 1100 handles this with a 500 fallback, so it should be fine.

As noted on app-router-entry.ts, this resolveStaticAssetSignal call is redundant when app-router-entry.ts already resolves the signal (because env is passed through to handler.fetch). The signal header is stripped by the first resolution, so this second call always returns null.

If the intent is for the deploy worker to be the resolution point (since it knows about env.ASSETS), then app-router-entry.ts should not resolve when env.ASSETS is present. If the intent is for app-router-entry.ts to handle it (so direct wrangler usage works), then this block can be removed.

Nit: pathname here (with .rsc suffix intact) vs cleanPathname (.rsc stripped) is a subtle distinction that's easy to misread. The logic is correct — pathname retains .rsc so the guard rejects RSC data fetches, while cleanPathname is the actual filesystem path to look up — but a brief inline comment would help future readers understand why two different variables are used in the same condition.

Minor: cancelResponseBody(response) is called after tryServeStatic regardless of whether serving succeeded. Since the signal response has a null body, this is a no-op, but if the signal construction ever changes (e.g., someone adds a body for debugging), the cancel call at this position is correct and defensive. Good.

The x-vinext-static-file header name is used as a string literal in three separate files (app-rsc-entry.ts template, prod-server.ts, worker-utils.ts). If this protocol ever changes, it's easy to miss one. Consider extracting it into a shared constant (e.g., in worker-utils.ts) that both prod-server.ts and worker-utils.ts can import, and that the entry template can reference via JSON.stringify().

Not blocking — the current test coverage (deploy.test.ts, app-router.test.ts, serve-static.test.ts) would catch a mismatch.

Clean approach — app-router-entry.ts is the single resolution point for the static asset signal on Cloudflare, and the deploy-generated worker (which wraps this entry) correctly delegates without its own resolution. The test at deploy.test.ts line 396-402 explicitly guards against the double-resolution regression. Well done.